Build process cleaned up and updated, looks like that now:

const componentsBuildIndex = require('./src/components-build-index');
const componentsBuildPages = require('./src/components-build-pages');
const componentsBuildScreenshots = require('./src/components-build-screenshots');

const globPattern = 'src/components/cards/*.html';
componentsBuildIndex(globPattern)
.then(componentsForNavPath => componentsBuildPages(componentsForNavPath))
.then(componentsForNavPath => componentsBuildScreenshots(componentsForNavPath))
.then(() => {
  console.log('All done');
})
.catch((err) => {
  console.log(err);
});

You may need Node 6 as I used ES2015 "modern" syntax :)

The first step, which builds the index, now create an intermediate file tmp/componentsForNav.json and returns that path to be used by other (asynchronous) steps, so that the code that finds the component name, paths, screenshot name, path, etc is not duplicated. The front matter is in there too. For example:

{
  "cards": [
    {
      "name": "Album Centered",
      "title": "Cards Album Centered",
      "src": "src/components/cards/album-centered.html",
      "path": "components/cards/album-centered/index.html",
      "href": "/components/cards/album-centered/index.html",
      "screenshot": {
        "path": "components/cards/album-centered/screenshot.png",
        "href": "/components/cards/album-centered/screenshot.png"
      },
      "frontMatter": {
        "bodyClass": "bg-white pt5"
      }
    },

Add component signature, a hash of the Tachyons version and component contents, so it can be used to bust the browser cache for screenshots. If the server delivering these pages is setup correctly, a user returning to the components page should not re-download the screenshots, but use the ones in the cache instead, UNLESS the signature has changed, in which case they will be re-downloaded. Win-win.

@mrmrs @johnotander I assume you are using Github Pages? We will have to test, it's unclear how caching is setup, though it might be something a bit too short like 10 minutes :( See javascript - Determining a page is outdated on github pages, How to solve caching problem with Github Pages, Caching assets in Github pages (github.io)

{
  "banners": [
    {
      "name": "Basic",
      "title": "Banners Basic",
      "src": "src/components/banners/basic.html",
      "path": "components/banners/basic/index.html",
      "href": "/components/banners/basic/index.html",
      "screenshot": {
        "path": "components/banners/basic/screenshot.png",
        "href": "/components/banners/basic/screenshot.png?version=71b1b1c5aac3d21f986dd404d9f0f70f"
      },
      "signature": "71b1b1c5aac3d21f986dd404d9f0f70f",
      "frontMatter": {
        "bodyClass": "bg-white pt5"
      }
    },

Script being run (only on the banners category):

Phew.

• build scripts were updated again, many configuration options can be overriden now (see src/components-build-defaults).

const componentsBuildIndex = require('./src/components-build-index');
const componentsBuildPages = require('./src/components-build-pages');
const componentsBuildScreenshots = require('./src/components-build-screenshots');

// See components-build-defaults for list of options
const options = {
  componentsGlobPattern: 'src/components/banners/*.html',
  componentsBuildPages: true, // false to skip
  componentsBuildScreenshots: true, // false to skip
};

componentsBuildIndex(options)
.then(() => componentsBuildPages(options))
.then(() => componentsBuildScreenshots(options))
.then(() => {
  console.log('All done');
})

• images are shrunk and saved as JPEG.

Done with components screenshots! (20.87 MB => 3.58 MB)

There you go, 21MB to 3.6MB already, and the optimizer is not even there.

There is no algorithm that can perfectly fit the screenshot in the gallery layout, but this can be tweaked per component. I reviewed 150 of them (again), and nudged them accordingly. In the frontmatter, one can play with any one of these to change the defaults:

{{{
  "bodyClass" : "bg-white",
  "screenshot" : {
    "autocrop": false, 
    "background-position" : "left center",
    "selector" : "[data-name=\"screenshot\"]",
    "background-size" : "contain"
  }
}}}

Scripts now show compression gain (from raw ONG capture to final, resized JPEG; no optimization for now)

Alright folks,

• The original 20.9MB of PNG screenshots capture for the components gallery are now resized and converted to JPEG, which decreased the load to 4.6MB.
• I then added an extra optimization layer using imagemin which brought this whole thing down to 1.72MB.
• I added lazy loading, so you are looking at only a few requests when you land on that page, and the rest is streamed as people scroll down.

I believe this should do the trick until you decide the gallery needs to be fragmented (I'm partial to a single page), but I got to work on other projects :) Hit me up though.

The compression quality and screenshot size can be tweaked in the future (check src/components-build-defaults.js).

@mrmrs @johnotander what do you think? You guys will be the ones adding components, I cleaned up build.js but let me know if this gets in the way of your development workflow. You may need a recent version of node.js.

I haven't committed the new, generated gallery, just the source files. Give it a shot. It slower though, unsurprisingly, it took about 5 mins to re-create it on a 2016 MBP.

With that being said it should be easy to create a "Featured" gallery, or an index to category pages, with only one "featured" screenshot per category in that index. I would slap: "featured": true in the front matter. As far as showing the most recent components, you could add a date there too, but git can tell us when a file was last added, git log --diff-filter=A -- foo.js, and there might be a NPM package to access that programmatically from a script (and that's nodegit).

Hey @sebastienbarre, thank you so much for your contribution. This is amazing!

Just ran the build and did some testing locally. Works perfectly. The lazy loading of the images keeps the main component page pretty lightweight which is way rad. Everything looks good to me 👍 but I'll wait for @mrmrs to have a look to see if he has any thoughts or wants to tweak things.

I appreciate the time you took adding feedback to the build process, too. That's an aspect we've been needing to improve for a very long time : ).

@sebastienbarre you are my hero. This is all really rad. Great example of how to put together a solid PR. Appreciate all of your hard work here. Excited to launch this.

Thanks folks, glad I could help.